Redact credential field names that logging missed - #1270

Summary

Closes all 7 CodeQL findings left open after #1266. CodeQL now passes with zero open alerts.

The high-severity logging alerts turned out to be real, not false positives — I verified the leak empirically before writing any fix.

The actual bug

log_event sanitizes its inputs before they reach any sink, so this looked like a false positive at first. It isn't. The redaction decision for structured properties came from _is_sensitive_log_key, which matched a fixed list of substrings. Several credential field names this codebase actually uses contain none of those substrings.

_normalize_log_key strips punctuation, so auth_key / authKey / auth-key all normalize to authkey — and the fragment list had accountkey, apikey, privatekey, subscriptionkey, but not authkey.

Reproduced on Development before the fix:

log_event("probe", extra={"auth_key": "SuperSecretCredentialValue123"})
-> [LOG] probe -- {'auth_key': 'SuperSecretCredentialValue123'}

That matters because auth_key is the field the action connection-test routes use for the caller-supplied secret, and the plugin manifest's auth.key is described in plugin.schema.json as holding "the secret value for the plugin ... such as a SQL connection string, a password for a service principal."

A value under one of these keys was only redacted by luck — when the value itself happened to match SECRET_ASSIGNMENT_RE (e.g. a connection string containing Password=). A bare API key or token was emitted verbatim.

18 credential key names were affected, including pwd, key_pair, master_key, primary_key, secondary_key, encryption_key, signing_key, session_key, and storage_key.

The fix, and why it's shaped this way

The obvious fix — treat any key containing key as sensitive — is wrong. It would redact key_encoding, key_prefix_hints, and partition_key_path, stripping diagnostic value from logs.

So this adds two things:

• the missing credential fragments (authkey, masterkey, keypair, encryptionkey, signingkey, sessionkey, storagekey, primarykey, secondarykey)
• a new exact-match list for names that carry a secret only when they are the whole key (key, keys, pwd, pass, passphrase, sig, signature)

This is timely: Development just shipped Test Connection for eight more action types, all of which handle caller-supplied secrets.

Also included

• py/import-of-mutable-attribute ×2 — completed the v0.250.047 import-binding cleanup in the two scripts it missed, using that fix's documented pattern. No direct CosmosClient imports remain anywhere in the repo. deployers/version.txt bumped per repo policy since deployers/ is touched.
• Revived a dead test — test_privacy_logging_telemetry_audit.py has been failing since v0.242.072 because it asserted an exact config.py version, so it errored before reaching a single assertion. That's the anti-pattern the repo's own version-assertion guidance forbids. Switched to assert_app_version_at_least. It's the privacy audit for the exact code this PR changes, so it was worth reviving rather than leaving silently red — it now passes 5/5.

Validation

The new test was confirmed to fail without the fix, reporting all 18 unredacted key names and reproducing the auth_key leak — so it's a real regression guard, not a tautology.

I also compared every logging-suite failure against unmodified Development by exit code: all deltas identical, zero regressions. Several logging tests fail on Development today for unrelated environment reasons.

Separately: one unrelated red test

test_logging_tag_standardization.py currently fails on Development — tags AUTH_CALLBACK, MIXED_SOURCE_ANALYZE, WORKFLOW_ALERTS, YAMCS_PLUGIN are missing from docs/reference/logging-tags.md. It's a small doc addition, but unrelated to these alerts, so I kept it out of this PR to preserve scope. Happy to fix it in a follow-up.